Switch NuGet publishing to trusted publishing - #6573

_{Comment @coderabbitai help to get the list of available commands.}

Greptile Summary

The PR replaces the long-lived NuGet API-key secret with an OIDC trusted-publishing login and forwards the resulting short-lived key into the existing pipeline.

• Grants the workflow matrix repository-write and OIDC-token permissions.
• Runs NuGet/login on main-branch Ubuntu publishing executions.
• Passes the login output to the existing package-publishing pipeline.

Confidence Score: 4/5

The PR appears safe to merge functionally, with non-blocking security hardening needed around permission scope and immutable action pinning.

The login and publishing conditions align and the pipeline safely handles an absent API key, but unrelated matrix executions inherit publishing privileges and the new login action can change without a repository-reviewed commit update.

Files Needing Attention: .github/workflows/dotnet.yml

sequenceDiagram
  actor Maintainer
  participant GHA as GitHub Actions
  participant NuGetLogin as NuGet/login
  participant NuGet as nuget.org
  participant Pipeline as TUnit.Pipeline
  Maintainer->>GHA: "Dispatch main workflow with publish-packages=true"
  GHA->>NuGetLogin: Run Ubuntu login with OIDC permission
  NuGetLogin->>GHA: Request GitHub OIDC token
  NuGetLogin->>NuGet: Exchange identity for temporary API key
  NuGet-->>NuGetLogin: NUGET_API_KEY
  NuGetLogin-->>GHA: Expose action output
  GHA->>Pipeline: Pass NuGet__ApiKey and ShouldPublish
  Pipeline->>NuGet: Publish generated packages

_{Reviews (1): Last reviewed commit: "Switch NuGet publishing to trusted publi..." | Re-trigger Greptile}

Code review

Reviewed the switch to NuGet trusted publishing (OIDC via NuGet/login@v1). Note: this PR is already merged, so these are retrospective/follow-up notes rather than blockers.

Verified as sound:

• The NuGet login step's if condition (ref == main && publish-packages == 'true' && ubuntu-latest) doesn't match the broader publish-packages flag passed to Run Pipeline (which omits the ref == main check). I initially flagged this as a mismatch that could leave nuget-apikey empty on a non-main dispatch, but UploadToNuGetModule (tools/TUnit.Pipeline/Modules/UploadToNuGetModule.cs) already guards with [RunOnlyOnBranch("main")] and skips cleanly via WithSkipWhen when the API key is empty — so this is a non-issue, no dead-key publish attempt occurs.

Worth a follow-up (non-blocking):

1. Elevated permissions apply to the whole OS matrix, not just the leg that needs them. contents: write / id-token: write are declared at the job level (.github/workflows/dotnet.yml line ~29), but the matrix runs on ubuntu-latest, windows-latest, and macos-latest. The modules that actually use these permissions (UploadToNuGetModule, CreateReleaseModule, PushVersionTagModule) are all [RunOnLinuxOnly]. Since GitHub Actions permissions can't be scoped per matrix-leg, the Windows/macOS jobs now carry a write-scoped + OIDC-minting token they never use, unnecessarily widening the blast radius if a dependency in those legs is ever compromised. Splitting publish/release into a dedicated job that runs after the test matrix (ubuntu-only) would let the test matrix stay on minimal default permissions while only the publish job gets the elevated scope.
2. NuGet/login@v1 is pinned to a mutable tag. This action mints a live, trusted NuGet-publish credential, so it's a high-value supply-chain target — if the v1 tag is ever repointed, this workflow would silently run whatever it points to with that trust. Standard hardening practice (and likely what a scorecard/pinned-dependencies check would flag) is to pin third-party actions used in privileged contexts to a full commit SHA.

Both were also flagged by greptile-apps' automated review; I independently verified them against the pipeline source rather than taking that at face value.